![【AWS Audit Manager】フレームワーク、コントロールを継続的デプロイしてみた](https://devio2023-media.developers.io/wp-content/uploads/2021/12/aws-audit-manager.png)
【AWS Audit Manager】フレームワーク、コントロールを継続的デプロイしてみた
こんにちは、AWS 事業本部コンサルティング部のたかくに(@takakuni_)です。
今回は、タイトルにあるとおり Audit Manager のフレームワーク、コントロールを継続的デプロイしてみようと思います。
今回行うのは以下のハンズオンです。
Continuous compliance monitoring using custom audit controls and frameworks with AWS Audit Manager
はじめに AWS Audit Manager とは
Audit Manager とは、AWS アカウント内のリソースがコンプライアンス違反していないかを継続的にチェックするリソースです。
コンプライアンス監査は非常に面倒でコストのかかるプロセスです。
- 定期的に行う必要がある
- 業界、企業によってルールが様々
- 第三者の監査企業に委託するケースもある(依頼から遂行までに時間がかかる)
上記の問題の解決方法の一つとして AWS Audit Manager が使用されます。
Audit Manager で何ができるのか
Audit Manager では、CIS ベンチマークを初めとした様々なセキュリティ規格をフレームワークで管理し継続的に監視することができます。
フレームワークには、最初から作成されているStandard frameworksと自身でカスタマイズするCustom frameworksがあります。
また、Standard frameworks から派生して、Custom frameworks を作成することも可能で Custom frameworks はAWS アカウント間で共有することもできます。
セキュリティ基準のライフサイクル
前述の CIS ベンチマークについて取り上げてみます。
CIS ベンチマークのバージョンアップデート日時は以下の通りです。
バージョン | 日時 |
---|---|
Initial | 2016/2/1 |
1.1 | 2016/11/9 |
1.2 | 2018/5/23 |
1.3 | 2020/8/7 |
1.4 | 2021/6/7 |
業界全体の大枠となる規格で、1-2 年にアップデートがかかっていることがわかります。
では、企業独自の規格は、1-2 年のアップデートのライフサイクルでしょうか。
企業によっては 1-2 年のライフサイクルよりも短く細かなアップデート(カスタマイズ部分)が起こると思います。
アップデートがあった場合、CICD を組み AWS 上でもセキュリティ規格を迅速にアップデートしたくなると思います。
今回の構成図
今回の構成は以下の通りです。
- セキュリティ規格担当者(Contorol Owner)は、最新の規格を S3 にアップデートします。
- S3 イベント通知を使用して、Lambda 関数を起動し Audit Manager で監視しているコントロールライブラリや、フレームワークライブラリを更新する。
前提条件
- Audit Manager を有効化しておくこと
- 端末にてスタック作成の権限付与されていること(構成図のリソース周り)
- AWS CDK を使うので
cdk bootstrap
までは完了しておくこと
Audit Manager 基盤の作成
かなり自動化されていますが、構成図のリソース一式を作成します。
# ソースのダウンロード
git clone https://github.com/aws-samples/enterprise-controls-catalog-via-aws-audit-manager.git
# ソースへの移動
cd enterprise-controls-catalog-via-aws-audit-manager/
./deploy.sh
S3 バケットの確認
作成された S3 バケットを確認するとframeworks/
とcontrols/
フォルダが作成されていました。
フォルダ内に、テンプレートファイルをアップロードすることで Audit Manager にアップデートがかかる仕組みのようです。
Audit Manager の確認
既に、カスタムフレームワークとして NIST Enterprise Framework が定義されており、コントロールも 2 つ定義、紐付けされている状態でした。
フレームワークのアップデート
コントロールテンプレートを作成し、Audit Manager で作成されたフレームワークをアップデートしてみようと思います。
コントロールの作成
新しいコントロールを追加するために yaml ファイルを作成し、S3 バケットにアップロードしました。
name: "DataSecurity-PublicAccessProhibited"
description: "Information and records (data) are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information."
actionPlanTitle: "All public access block settings are enabled at account level"
actionPlanInstructions: "Ensure all Amazon S3 resources have public access prohibited"
testingInformation: "Test attestations – preventive and detective controls for prohibiting public access"
tags:
ID: "PRDS-3Subcategory: Public-Access-Prohibited"
Category: "Data Security-PRDS"
CIS: "CIS17"
COBIT: "COBIT 5 APO07-03"
NIST: "NIST SP 800-53 Rev 4"
datasources:
- sourceName: "Config attestation"
sourceDescription: "Config attestation"
sourceSetUpOption: "System_Controls_Mapping"
sourceType: "AWS_Config"
sourceKeyword:
keywordInputType: "SELECT_FROM_LIST"
keywordValue: "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS"
新しいコントロールが作成されていることが確認できました。
フレームワークのアップデート
S3 バケットに作成されていた、「enterprise-framework.yaml」を以下のように更新しました。
name: "NIST Enterprise Framework"
description: "NIST Enterprise Control Framework customized"
complianceType: "NIST"
controlSets:
- name: "DataSecurity"
controls:
- "DataSecurity-DataAtRest"
- "DataSecurity-DatainTransit" # 更新部分 deploy.sh で作成したフレームワークにコントロールを追加する
- "DataSecurity-PublicAccessProhibited"
tags:
Owner: AWSSamples
Company: AWSLabs
想定通り、フレームワークに新しいコントロールが追加されていることが確認できました。
まとめ
今回のハンズオンでは、S3 バケットのオブジェクトアップロードをトリガーに、Audit Manager のコントロール、フレームワークの自動作成、更新を行いました。
作り込みがさらに必要ですが、アセスメントの実行も自動化できればより迅速にコンプライアンス監視が行えそうです。
この記事が参考になれば幸いです。
以上、AWS 事業本部コンサルティング部のたかくに(@takakuni_)でした!